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Abstract 

The purpose of this paper is to identify a 
systematic process for improving ground operations 
for future launch systems. This approach is based 
on the Total Quality Management (TQM) continous 
improvement process. While the continuous 
improvement process is normally identified with 
making incremental changes to an existing systems, 
it can be used on new systems if they use past 
experience as a knowledge base. In the case of the 
Reusable Launch Vehicle (RLV), the Space Shuttle 
operations provide many lessons. 

The TQM methodology used for this paper will 
be borrowed from the United State Air Force "Quality 
Air Force” Program. There is a general overview of 
the continuous improvement process, with 

concentration on thejormulation phase. During this 
phase critical analyses are conducted to determine 
the strategy and goals for the remaining 
development process. These analyses include 
analyzing the mission from the customer point of 
view, developing an operations concept for the 
future, assessing current capabilities, and 

determining the gap to be closed between current 
capabilities and future needs and requirements. A 
brief analyses of the RLV, relative to the Space 
Shuttle, will be used to illustrate the concept. 

Using the continuous improvement design 
concept has many advantages. These include a 
customer oriented process which will develop a more 
marketable product and a better integration of 
operations and systems during the design phase. 
But, the use of TQM techniques will require changes, 
including more discipline in the design process and 
more emphasis on data gathering for operational 
systems. The benefits will far outweigh the 
additional effort. 

Introduction 

The top emphasis in the launch vehicle design 
world is the reduction of launch costs. This emphasis 
is illustrated by the increasing number of low cost 
launch systems in study, design, and early 
operations. Why all this sudden interest in reducing 
costs? 


There are several major reasons. First, the 
government, a major user of launch services, has 
decided to launch its payloads (where feasible) on 
commercial launch vehicles. Given that most 
government agencies will be forced to reduce their 
budgets, the government will be looking for the most 
economical and efficient launch systems. Second, 
the marketing of launch services to commercial 
industries is also an area of increased competition. 
The Ariane launch system continues to be the 
predominant player in the launch services arena, but 
it apd the U. S. launch vehicle manufacturers will 
face increased competition from Japan, Russia, and 
China. Finally, many believe that if launch costs can 
be reduced sufficiently then new customers for 
launch services will enter the market. 

But is launch cost the only factor? More likely 
the customer for launch services, a government or 
private entity, is looking for the best value. To the 
launch services customer value maybe a function of 
cost, dependability, reliability, or other factors. 
Value to the customer is the heart of Total Quality 
Management (TQM). 

It is the purpose of this paper to look at the 
design of operations for new launch systems from 
the Quality perspective. Unfortunately this paints a 
rather broad perspective, so some limits must be 
established. First, the paper will be limited to 
reusable launch vehicles, and more specifically to 
the vehicle turnaround process. These are the 
actions necessary to process the vehicle from the 
landing on one mission to liftoff on the next. 
Turnaround operations were selected because they 
are a key value driver in reusable launch system 
operations. Second, the examples utilize the 
proposed Reusable Launch Vehicle (RLV) with 
Space Shuttle operations providing the knowledge 
base. Third, because it is impossible to evaluate the 
specific operations for every RLV configuration, the 
level of analysis will be kept at the subsystem level. 
In turn, the subsystems considered will include only 
those common to most RLV configurations. 
Fortunately most configurations have the same basic 
subsystems. Finally, this paper does not intend to 
provide solutions for improving launch system 
turnaround processing. Rather this is an example of 
how TQM should be applied to the questions of 
ground processing and customer value 
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Continuous Improvement 

The heart of Total Quality Management is 
continuous process improvement. Continuous 
process improvement is a systematic, iterative 
method of improving a process. Many organizations 
have instituted continuous process improvement, 
each using an approach best suited for their 
environment. 

The basis for this analysis is the Quality Focus 
method used by the United States Air Force as part 
of the Quality Air Force (QAF) program. This 
approach was selected because it is essentially 
driven by aircraft operations. (Since the RLV is 
striving toward aircraft-like operations this appears to 
be a good match.) In addition, it has the advantage 
of being well documented. 

Quality Focus is an iterative process based on 
the Shewhart cycle, in which there are four stages 
for each process review iteration. [1:71] These are 
plan, do, study, and act. During the planning stage 
data is gathered on the existing process and it is 
analyzed for potential areas of improvement. Based 
on the results of Jhe planning stage, potential 
improvements will be implemented on a small scale 
during the “do" stage. During the study stage the 
results of the pilot projects will be analyzed to see if 
there are significant improvements. Finally, If there 
are significant improvements, the improvements 
will be made a permanent part of the process during 
the “act" stage. [1 :233] 

The Air Force Quality Focus method tailors the 
Shewhart cycle to fit the activities necessary for 


process planning. The relationships between Quality 
Focus and the Shewhart Cycle are illustrated in 
Figure 1. As illustrated in the figure the Quality 
Focus is also broken down into four phases; 
formulation, deployment, implementation, and 
review. As noted in the illustration these phases 
overlap the stages of the Shewhart cycle. [1 :71] 

The formulation phase of the cycle develops a 
plan for implementing continuous improvement. 
During this phase the organization determines the 
purpose of the process by clearly identifying the 
organization's mission, its customers, and the 
customer's needs, requirements, and desires. It 
evaluates where the organization is now and where it 
wants to be in the future with respect to its goals. 
Finally the organization determines the gap between 
the two, and sets goals and objectives for making 
the improvements. [1:71] 

The second phase of the quality focus is 
deployment. This phase also considers the goals 
and objectives of the effort. This is repeated since 
there are often trade-offs to be made between the 
formulation and deployment stages. Based on the 
goals and objectives, functional plans are developed 
for implementation of changes. [1 :74] 

The third phase of Quality Focus is 
implementation. Here the functional plans 
developed in the previous phase are used to make 
corrections to the process flow. But implementation 
does not stop here, data must be collected for use in 
the final phase of the process. [1 :75] 

The final phase is the review of the data 
collected to ascertain if the changes to the process 
are effective. If the reviews show a positive result. 



Figure 1 : Air Force Quality Focus Method 
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the changes are made to the process, and the 
continuous improvement process goes to the next 
iteration. In doing so, the process is refined to best 
meet customer needs [1 :77] 

This paper will only focus on part of the 
formulation phase of the Quality Focus process. 
There are several reasons for doing this. First, is 
that the entire process is far beyond the scope of this 
paper. It would be very difficult with a generic 
vehicle to the determine functional plans, and 
impossible to implement and review those plans. 
Second, it is the purpose of this study to 
demonstrate a method of analyzing ground 
operations, not in suggesting changes which would 
be dependent on a vehicle configuration. 

The Formulation Phase 

The components of the formulation phase and 
their definitions are illustrated in Figure 2. Those 
items in bold print are the portions of the formulation 
stage that are relevant to this paper. The others 
including Planning to Plan, Values Assessment, and 
Develop Strategic Goals and Objectives must be 
determined by the_ organization conducting the 
process and are again outside the scope of this 
study. 


• Planning To Plan 

• Values Assessment 

• Analyze Mission 

• Envision The Future 

• Assess Current Capabilities 

• Gap Analysis 

• Develop Strategic Goals And Objectives 
Steps In Bold Are Covered In The Paper 

Figure 2: Steps Of The Formulation Stage 

The first two steps to be considered are an 
analysis of the purpose of the process and 
envisioning how we would like the process to be in 
the future. To analyze the mission it is necessary to 
determine what is of value to launch service 
customers. Based on what the customer perceives 
as value, we will envision a turnaround process and 
vehicle design that will meet those needs. 

The remaining steps of the formulation phase 
are to determine current process capabilities, and 
the gap between those capabilities and our “vision” 
of the future. To accomplish these steps requires 
one key assumption. That is the new turnaround 
process will be a refinement of an existing 
turnaround process. For our example, the RLV 
process would be based on the Space Shuttle 


process. While many would like the RLV process to 
be entirely new and separate from earlier Shuttle 
operations, such an approach has many pitfalls. 
Most RLV configurations will require many of the 
same processes that the Shuttle currently requires. 
While we can not afford to repeat the mistakes of 
the Shuttle process, neither can we afford to ignore 
the lessons learned. For this study the Shuttle and 
its turnaround process will be our current capability, 
and the gap between the Shuttle process and our 
vision of the RLV future will determine where the 
current process must be changed. 

Analysis Mission 

Simply stated the purpose of the RLV system is 
to provide launch services to Low Earth Orbit (LEO). 
This is to be accomplished providing the greatest 
value to the launch services customer, while 
providing the vendor of launch services a 
reasonable profit. One of the keys to customer 
value is found in turnaround operations. 

The mission of turnaround operations is to return 
the vehicle to flight status after the preceding 
mission. This includes safeing the vehicle, 

conducting necessary inspections, replacing 
components that have failed (or that are estimated 
to fail during the next mission), and servicing the 
vehicle for the next mission. How this is 

accomplished, including the time allotted, is 
determined based on customer requirements. 

But customer requirements have many factors, 
with varying importance depending on the 
customer’s activities. A presentation by Rhodes [2] 
of NASA KSC, at the AIAA Space Operations and 
Support Technical Committee, Low Cost Operations 
Workshop provides breakdown of these factors. 
While the original purpose of the presentation was 
launch system affordability, it closely relates to 
customer value. 

Figure 3 illustrates the breakdown of affordability 
factors. At the top of the hierarchy is the overall 
affordability of the launch system. This is in turn 
broken down into non-recurring and recurring costs. 
In other terms, these are the cost of system 
development and system operations respectively. 

Non-recurring costs can be broken down into 
program acquisition cost and technology research 
and development. Technology research and 
development costs are the long-lead investments 
necessary to identify, develop, demonstrate, and 
mature technologies so that they are ready in time 
for system development. Program acquisition costs 
are the costs of system development. This includes 
the actual cost of design, manufacturing, and their 
infrastructure; as well as costs related to 
programmatic and technical risk. The impact of non- 
recurring costs on the customer value depends on 
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how the system operator decides to amortize their 
investment. This falls outside the scope of this 
paper. 

Recurring costs-are the main focus because 
these costs are directly related to turnaround 
operations. In addition, these costs will make or 
break the marketability of a reusable launch system. 
Like non-recurring costs, recurring costs can be 
broken down into two areas, dependability and 
responsiveness. These areas, in addition to vehicle 
performance are the key drivers of customer value. 

Dependability is the ability of the system to 
perform as scheduled. This includes both the 
timeliness of a mission as well as the success of the 
mission. It can be broken down into three factors; 
Reliability, Performance Assurance, and Launch on 
Time. Reliability is the probability that the system 
will operate as planned. For the RLV, reliability Is 
measured with three factors: (1) mission reliability, 
the probability of flying the mission as planned, (2) 
vehicle recoverability, the probability that the vehicle 
will survive a mission, (3) passenger safe return, the 
probability of recovering the passengers (even if the 
vehicle is lost). The value of reliability to the 
customer depends on their needs. For example, if 
the customer is considering whether to launch on an 
expendable or reusable system, mission reliability is 
primary; vehicle recovery is the operator's problem. 
For a Space Station crew rotation mission, all three 
reliability parameters are important. In this case, the 
customer is concerned with all mission phases from 
launch to the safe return of the station crew and the 
recovery of experiments being returned from orbit. 

Dependability is also a function of performance 
assurance. This is the vehicle’s robustness including 
operating margins and fault tolerances. Increased 
performance assurance means that the system has 


greater flexibility. The value to the customer here is 
the vehicle's ability to operate in a wide variety of 
conditions. The more restrictive the performance 
assurance, the more likely are launch delays. 

Finally, dependability is a function of the 
systems ability to launch on time. This means that 
the launch system and its various processes are 
designed to meet the requirements of the mission 
manifest. Timeliness is based on the launch date 
set when the customer contracts for services, not 
when the vehicle is available for flight. The value to 
the customer is confidence in the launch date. 

The second area under recurring costs is 
responsiveness. It too can be broken down into 
greater detail. Its components are Flexibility, 
Launch Rate, and Operability. For the customer 
flexibility means that the system is capable of 
changing to meet their needs rather than the other 
way around. Responsiveness is also a function of 
launch rate, which in turn is related to flexibility. 
Responsivness is the capability to have the system 
available on demand, and to accommodate rapid 
response requirements. 

Finally responsiveness is a function of 
operability. Operability is the attributes of the launch 
system that allow it meet mission requirements and 
manifesting. To the customer, operability is a direct 
concern, since the impact of operability is manifest 
in the other factors of dependability and 
responsiveness. In addition, operability is a major 
impact operating costs which are transferred to the 
customer. 

Operability breaks down into Maintainability, 
Supportability, and Simplicity. Maintainability is a 
design factor that measures the ability of the 
operator to maintain the system. It measures 
include vehicle service requirements, access to 
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vehicle systems, and the processes necessary 
maintain the vehicle; with simplicity being the key. 
Another consideration of operability is supportability. 
Supportability is what it takes to support system 
operations. It includes such diverse areas as 
logistics, personnel, and administration. Again the 
key is simplicity. The last factor is simplicity of 
design. The less complex the systems, the less 
likely there will be failures. Again these are not really 
value items for the customers to consider, rather 
they are factors that the system designers and 
operators must consider to drive theose parameters 
which are of value to the customer. 

In summary, the value of launch services is in 
the eyes of the customer. Since it would be beyond 
the scope of this paper to survey customer 
requirements, the following assumption is made; 
For the launch services customer, the primary 
factors in the value of services are cost, reliability, 
flexibility, and schedule dependability. The 
customer would expect to pay a reasonable price for 
the launch services. Which would drive the launch 
system operator to streamline turnaround operations 
as much as possible. The customer also values the 
reliability of the system. Which would drive the 
turnaround process- to ensure that required 
maintenance and servicing is accomplish before 
flight, but without adding unnecessary inspections 
which drive costs up. Flexibility is also assumed to 
be major value point for the launch services 
customer. It ensures the customer that special or 
changing mission requirements can be met. Finally, 
schedule dependability ensures that customer that 
the contracted services will be there when required. 

Future Vision 

The second step of the quality focus method is 
the future vision, a vision of where we want to be. 
One source of this vision is the Cooperative 
Agreement Notice (CAN) for the Reusable Launch 
Vehicle Demonstrator (X-33). [3] While this 
document was concerned with a demonstrator of 
technologies required for a reusable launch vehicle, 
it also calls out goals for a future RLV. 

Table 1 lists the minimum operations 
requirements for the reusable launch vehicle. Each 
of these requirements will be an improvement to the 
existing capabilities of the Shuttle. This includes the 
automation of pre-flight and flight operations, a 
seven day maximum turnaround and a 3.5 day 
maximum emergency turnaround. Under operability 
there are requirements for schedule dependency and 
robustness. Finally for reliability it includes 


probabilities for safe recovery of the vehicle and the 
crew. 1 


Table 1: X-33 CAN Requirements And 
Goals For RLV 


• 

Automated pre-flight and flight 
operations (launch, ascent, on-orbit, 
reentry and ianding 

Req 

• 

The flight vehicle shall be capable of 
safely aborting to the launch site 
during the ascent phase if required 

Req 

• 

Seven day maximum mission duration 

Req 

• 

Seven day ground processing time 
from landing to launch 

Goal 

• 

3.5 day ground processing time from 
’ fending to launch for reflight under 
emergency conditions 

Goal 

• 

The probability of launching within 
TBD (sic) days of scheduled is .95 

Req 

• 

Maximize responsiveness to adverse 
weather conditions 

Req 

• 

Launch and landing at same location 
(nominal condition) 

Req 

• 

The flight vehicle shall be capable of 
unplanned landing at alternative 
landing sites with minimal support 
equipment and facilities 

Req 

• 

To the extent practical, on-board 
subsystems required for flight vehicle 
shall be field repairable/replaceabie 

Req 

• 

Equipment required to repair, process 
and return vehicle to launch site shall 
be transportable 

Req 

• 

.995 Probability of safe recovery of the 
flight vehicle per mission 

Req 

• 

.999 Probability of safe recovery of the 
human passengers per mission 

Req 


The requirements spelled out in the CAN drive 
the overall goals of a new launch vehicle, but they 


1 There is no reliability given for mission reliability. 
In fact the .995 probability vehicle recovery has 
proven to be a much more stringent requirement on 
the system than the .98 mission reliability that has 
generally been mentioned. 
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do not give any direction on how those goals will be 
achieved. It would be up to the system developer to 
determine guidelines for meeting the overall goals. 
An example of these guidelines, is illustrated in 
Table 2. This is a “vision" of an RLV operations 
concept developed by the Vehicle Engineering 
Directorate at the Kennedy Space Center. [4] 

This list is a “vision" of the attributes that a future 
launch system would have based on past experience 
with other launch systems, particularly the Shuttle. It 
is not a list of requirements, but rather goals to be 
met in the future. The “vision" calls for a system 
that is highly automated or autonomous, meaning 
less of a standing army and Ground Support 
Equipment (GSE) necessary to process the system. 

It also calls for a more simplified and robust vehicle 
that has wider operating margins requiring fewer 
periodic inspections and vehicle type certification 
like aircraft, rather than individual flight certification 
as on the Shuttle . The processing of the system is 
also more simplified and interfaces -between the 
ground and payloads are more standardized. 
Finally, it envisions a system where operations, 
vehicle systems, and payloads all have an input into 
the vehicle design. 

In summary, the'Tuture vision of a launch system 
is a goal that we are designing to reach. For this 
example the assumed vision of turnaround 
operations is a relatively simple process that is 
conducted with a high degree of automation. The 
process is relatively uncomplicated and strives 
toward aircraft operations, meaning replenishment of 
consumables and correction of failures. There is no 
recertification with attendant testing and inspections. 
The process is highly reliable and robust, meaning 
few failures of flight and ground systems during 
processing. The process meets scheduled launch 
dates with a high degree of dependability, and is 
highly flexible, capable of accommodating late 
changes to payload or schedule. 

Assess Current Capability 

The next step is to evaluate our current capabilities, 
in this case the current status of the Space Shuttle. 
Because of the many aspects of turnaround 
processing, a proper assessment would again be far 
beyond the scope of this paper. As a result we will 
consider only the value of schedule dependency to 
the customer in our RLV / Shuttle example. 

One of the major criticisms of the Space Shuttle 
is its launch delays. While the most publicized of 
the delays are on-pad delays, there are many other 
delays that account for a much greater schedule 
slips. In fact changes in the launch date are based 
on three factors: First, the variability in mission 

planning times. Second, variability in vehicle 
turnaround processing times. Finally, the impact of 


Table 2: RLV Operations Concept “VISION” 

• Provide a simplified, very-highly automated 
vehicle enabling minimum periodic and 
repetitive maintenance. 

• Strive to isolate vehicle ground processing 
from dependence on facilities and GSE. 
Routine turnaround should replenish 
consumables only. 

• Promote vehicle health monitoring / 
management systems and self-test at a level 
which supplies only O&M related information 
that requires corrective action prior to next 
flight. 

• Eliminate “flight readiness-style" vehicle 
recertification for every flight. Provide 
aircraft-style vehicle-type certificate. 

• Design in performance margins and flight 
hardware allowances to eliminate processing 
impacts (i.e. strive to eliminate unscheduled 
work.) 

• Reduce operations and hardware complexity 
for maximum utilization of resources and 
eliminate opportunity for human-induced 
system failures. 

• Employ near autonomous ground 
management planning at top levels. Focus 
on automatic interactive scheduling of flight 
vehicle, ground support facilities, and 
support logistics. 

• Adapt minimum standardized payload 
interfaces to assure maximum flexibility and 
affordability. 

on-pad delays due to weather, and ground or flight 
system failures. 

Delays due to mission planning occur from the 
time the customer and the operator agree on a 
contract for launch services until all planning and 
preparation for the mission are complete. For the 
Shuttle, delays are due to changes in the manifest; 
delays in planning mission timelines, crew training, 
and unavailability of facilities or equipment. Many of 
these problems are due to the need to assign a 
specific vehicle to the mission earlier in the process. 
This is due to differences in vehicle flight attributes 
and can make a mission dependent on all of the 
prior missions using that vehicle. Unfortunately there 
is no data kept on this type of delay. As a result it is 
impossible to assess the problem or to develop an 
analysis of the gap between the current process and 
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our envisioned process. Fortunately the general 
RLV concept calling for “mass produced”, identical 
vehicles with standard payload interfaces may take 
care of this type of delay. In addition, automated 
mission planning may also make the planning 
process more adaptable to changes. 

Ground processing delays are the delays that 
occur because of vehicle and ground systems 
problems from the time the vehicle lands from the 
previous mission to the time the next countdown 
starts. These delays can be attributed to either 
vehicle system failures or failures in the turnaround 
process. Since we would like to have the greatest 
impact for the design dollar, our assessment must 
identify which subsystems and processes are giving 
us the greatest problems. 

Vehicle systems failures impact two customer 
concerns, reliability of the system and schedule 
dependability. To properly evaluate subsystem and 
component reliability a large data base pf 
component failure data is required. Unfortunately, 
the Shuttle data collection system is not designed to 
track component failure rates. As an indicator of 
relative subsystem failure rates we will use the 
historical vehicle flight failure data. 

Figure 4 [5:78] shows the distribution of failures 
attributed to each subsystem for vehicle failures 
(excluding failures attributed to payloads or upper 
stages). The bars labeled for all failures consider all 
launches by any vehicle ever used for space launch 
operations, with data going back to 1954. For 
ballistic missiles later used for space launches, it 
includes the ballistic launches. The data is also cut 
for launches after 1970. These are assumed to be a 
better indicator of current capability, since they do 
not include early launches by less sophisticated 
vehicles. 

Note that Figure 4 is for loss of mission. A loss 


of mission failure for the RLV is defined as a failure 
where the vehicle could not complete its mission. 
This type of failure may or may not result in the loss 
of the vehicle. This results in an obvious conflict with 
expendable vehicles which are never recovered, and 
which make up the vast majority of historical data. 
Because there is so little historical data on reusable 
vehicles, it is necessary to use the expendable data 
to get a better estimate of current launch vehicle 
reliability. Since expendable and reusable launch 
vehicle have many similar subsystems, though 
operating for different periods of time, it seems 
reasonable to use the data for a first cut at 
reliabilities. 

In examining the figure, note that the propulsion 
system has always been a major contributor to loss 
of mission. For this analysis, the propulsion system 
is considered to be anything up stream of the 
turbopumps, including fuel storage and feed 
systefris, vent/purge systems, and the pressurization 
system. While it appears that this problem is worse 
in the 1970 and later data, this can be deceiving. 
What this data shows is the percentage of all failures 
by subsystem. The reliability of the propulsion 
system is improving, but not to the extent of other 
subsystems. As a result, the proportion of failures 
contributed by the propulsion system is considerably 
greater. 

Based on the historical data a success ratio, 
total success/total launches, can be derived. The 
values for current launch vehicles (expendable and 
reusable) flown since 1970 are listed in Table 3. 
This data will be considered as the current level for 
subsystem reliability. In the next section we will 
compare it to the what is required in the RLV vision. 

As noted earlier, turnaround process reliability 
also impacts customer value. A study by Flemming 
[6] of Lockheed Martin, looked at the impact of 



Figure 4: Breakdown Of Vehicle Flight Failures By Subsystem 
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process reliability on turnaround processing flow 
times. The reliability of a process for this study was 
the percent of the time when no problems were 
encounter during that specific process. The study 
looked at the seven processes that are part of the 


Table 3: Estimated SubSytem Reliability 

Subsystem 

Success Ratio 

Structures 

.9979 

Propulsion Systems 

.9764 

Engines 

.9914 

Thermal Protection System 

.9979 

Attitude Control System 

.9979 

Avionics 

.9935 

GN&C 

.9999 

Power 

.9936 

Other Avionics 

.9999 

Human 

.9936 

Other Unknown 

.9936 


overall Shuttle turnaround process. These include 
mechanical, electrical, propulsion, thermal 
protection, avionics, and landing gear system 
checkouts; and propellant loading. 

The study used Problem Report (PR) data from 
the Shuttle turnaround process. This data consisted 
of the number of process runs that contained 
failures, the total number of process runs, and 
measures of Mean Time To Repair (MTTR). 
Actually the evaluation used three measures of 
MTTR. The first (MTTR 1) was hands-on repair time 
which starts when troubleshooting is complete and 
continues until the repairs are complete except for 
testing and closeout. The second measure (MTTR 
2) is active repair time and includes all of the first 
measure plus troubleshooting, test time, and 


closeout. The final measure of MTTR (MTTR 3) is 
the overall repair time which includes active repair 
time plus any administrative time. With the MTTR 
calculated, the dollar cost of process unreliability can 
be calculated by using a average hourly 

compensation rate. 

A summary of the data for the Shuttle 
turnaround process (current baseline) is shown in 
Table 4. The data includes the process success 
ratio for each of the listed areas. The data will be 
used to determine the process reliability “gap" 
between the current turnaround process and the 
reliability required to fit the time constraints of our 
RLV vision. 


Table 4: Current Shuttle Process Reliability 

Success 

. , Process 

Ratio 

Propulsion Systems Checkout 

.80 

Mechanical Systems Checkout 

.64 

Electrical Systems Checkout 

.72 

Avionics Systems Checkout 

.63 

Thermal Protection System Checkout 

.60 

Landing Gear Checkout 

.25 

Propellant Loading 

.20 


The final type of delay to be evaluated is the on- 
pad delay. While these delays generally result in the 
least impact to the scheduled launch date, their 
visibility to the public and the media give them much 
more weight. The impact of these delays may 
increase with the start of space station missions. 
These missions require much shorter launch 
windows due to the need to reduce orbital phasing 
times to a minimum. The phasing time needs to be 
minimized since longer times in orbit will drive the 



Figure 5: Comparison Of Shuttle And RLV Launch Delays 
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design of the subsystems and will usually result in 
unacceptable weight increases. It is generally 
accepted that a launch window of five minutes will 
be allowed. 

The launch delay data illustrated in Figure 5 is 
for the Space Shuttle, and was collected by Weldon 
[7] of NASA MSFC. The figure shows the number of 
delays attributed to weather, and vehicle systems. 
The data includes both delays that extend beyond 
the launch day, and delays that result in a launch 
later in the window, but in the same day. As the 
figure shows, weather at the launch site or at the 
abort sites (coded L/L) cause the most delays. 

But this data can be misleading. Figure 6, 
based on Lockheed Martin Operations data [8], 
compares the number of delays to the cumulative 
length of the delays. When the data is based on the 
number of delays, regardless of length, weather is 
the largest cause of delays. When the data is based 
on the cumulative number of delay days, then the 
liquid propulsion system is biggest contributor to 
delays. To the customer the latter is the true driver. 
It is many times important to look at data from 
several different views to determine the true 
problem. 

Note that this data is only down to the subsystem 
level, which is sufficient for this example. In 
actuality the data must be down to the component 
level to be useful for continuous improvement 
efforts. It is essential that future launch systems 
develop a data collection and analysis system prior 
to the vehicle going operational. Lack of such a data 
collection system for the Shuttle is a major 
shortcoming in attempting to apply past experience 
to future programs. 


Gap Analysis 

The final step that we will take in our analysis of 
turnaround processing will be that of gap analysis. 
This determines the gap between what our current 
capability and the capability of our 'Vision" of the 
future. The product of this analysis is a list of 
problem areas that must be solved to maximize 
customer value. Prioritizing this list by customer 
value will result in maximizing customer satisfaction 
with limited funds. As noted in the previous section, 
schedule dependability is based on vehicle and 
process reliability, and on-pad launch delays. We 
will first consider vehicle reliability. 

To determine the gap between our current and 
required reliability it is first necessary to determine a 
quanjihable vision. The X-33 Cooperative 
Agreement Notice (CAN) provides two goals, a .995 
probability of vehicle recovery and a .999 probability 
of safe passenger return. Which of these two goals 
drive the system design depends on the vehicle 
escape system and other factors. To simplify things 
we will go with the vehicle recovery goal. 

Subsystem goals can be achieved by allocating 
“allowed" failures between the subsystem based on 
the historical distribution of failures. In this case a 
reliability of .995 means that nominally there would 
be five failures per thousand flights. If in the past, 
propulsion system failures (not including engine 
failures) accounted for 40 percent of the failures 
then 40 percent of the five failures would be 
allocated to propulsion systems. The result would be 
a goal of two failures per thousand flights or .998 
reliability. The allocations can be made down to 



Cause Of Delay 


Figure 6: Number Of Delays Vs. Days Delay 
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whatever level that failure data allows. 

Once the reliability goals are determined it is 
necessary to evaluate what will be necessary to 
meet those goals. In the case of reliability goals, 
reliability growth 2 of existing systems must be 
projected to determine if the reliability goals can be 
met with reliability growth alone. If it can not be 
accomplished then it is necessary to look to new 
designs and processes. 

There are many methods which can be used to 
assess reliability growth. The results of two such 
methods are illustrated on Table 5. The columns 
title “Trend Estimate" and “Trend Forecast" are 
based on a regression equation that is an estimate of 
the instantaneous success ratio (total success over 
total flights). The “Trend Estimate” is an estimate of 
the current success ratio calculated from the 
equation for the present number of flights. The 
“Trend Forecast" is an estimate of subsystem 
reliability for 200 flights into the future. The value of 
200 was used because the average U.-S. flight rate 
(all vehicles) is about 20 flights per year multiplied 


by the ten years (at the time of the study) until the 
RLV is operational. These estimates were derived 
from a trend model fitted to data in the United States 
Launch Experience Data Base maintained by MSFC, 
Program Development, Operations Analysis Branch. 

[91 

The last column on Figure 7, entitled “Rockwell 
Estimate” is based on projects using the Rockwell 
MATrix model. The model is based on Shuttle data, 
and uses a proprietary model to forecast reliability 
based on vehicle characteristics and attributes. The 
results show a much more optimistic view of meeting 
our reliability goals because it assumes greater 
reliability improvements than simply reliability growth 
from flying the same hardware more often. The 
point is that in analyzing the gap you must be clear 
on the quality of the data, the accuracy of the 


2 Reliability growth is the increase reliability of a 

product as it matures. High failure rates in the early 
in the product give way to lower rates as the design 
matures. Thus, more testing and operational data 
should show fewer failures causing the reliability to 
grow. 


modeling techniques, and the assumptions 
necessary to gain the results. 

For the case illustrated here, the reliability 
estimates in the column titled “Trend Estimate" may 
be considered lower bounds on subsystem reliability. 
Future launch vehicle subsystem reliability should be 
at least as good as these estimates. The estimates 
in the column “Trend Forecast" suggest that 
subsystem reliability for launch vehicles has, in 
general, been improving since 1970 and may be 
expected to improve. The Rockwell predictions, in 
turn, may be considered achievable upper bounds 
on subsystem reliability. The allocated reliability for 
all but one subsystem (engines) are less that the 
Rockwell estimates. This would indicate that 
improvements in reliability, beyond that of reliability 
growth, are required to meet the goals. In any case 
development goals and strategies would be based 
on the gap analysis and the confidence in the 
results. 

The gap analysis of ground process reliability 
requires a comparison between the current Shuttle 
turnaround process and the 
turnaround process vision. This 
includes: (1) Develop a “vision" 
ot turnaround processing. (2) 
Determine the time required to 
accomplish each task based on 
previous experience. (3) 
Allocate the turnaround 
processing goal to process steps. 
(4) Determining the variability 
(reliability) of each task. (5) 
Prioritize process steps requiring 
change by cost to benefits ratio. 

The first three tasks of the process analyses 
require the development of a turnaround processing 
timeline. Figure 7 illustrates an example of a 
turnaround processing flow [5:1 II] 3 . The example is 
derived from a Shuttle flow, essentially without 
modification. It is based on a generic RLV which 
contains subsystems common to most current RLV 
designs. Further, it was designed to match a 96 
hour turnaround goal and individual task times are 
allocations. Note, this in no way indicates that this 
process flow is feasible, because it simply 
proportions time. 

The next step would to be to validate the 
process by determining the feasibility of the process 
times, and by eliminating those tasks that are 
unnecessary for the specific RLV design. This step 
can be long and involved. It would require breaking 
the each task down to the lowest level possible and 


3 This is just and example, and does not fit the RLV 
need for a quick turnaround 


Table 5: Reliability Allocations And Projections 


Subsystem 

.Allocation 

Trend 

Estimate 

Trend 

Forecast 

Rockwell 

Estimate 

Structures 

.9994 

.9854 

.9870 

.9996 

Prop. Systems 

.9982 

.9311 

.9411 

.9984 

Enqines 

.9994 

.9943 

.9943 

.9943 

TPS 

.9999 

* 


.9999 

Avionics 

.9993 

.9666 

.9726 

.9998 


' indicates That This Was Not Considered 
Data Base On Launch Data Since 1 970 
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Figure 7: Example RLV Turnaround Flow Allocated For 96 Hour Turnaround Goal 



determine whether each subtask is required, then 
summing the times back to the task level. To do this 
requires an adequate data base of historical tasks 
and timelines. Unfortunately, the availability of such 
data is limited, since operational data is not readily 
available at the component level. 

As a final comment the example obviously does 
not fit the vision that we set forward earlier. But it is 
indicative of the long way that we will have to go 
from the first generation reusable vehicle (Shuttle) to 
the next generation (RLV). 

Assuming that the example turnaround 
processing flow has been validated, it is now 
necessary to look at the reliability of the process. 
Table 4 presented the reliability for various tasks 
within the turnaround process. Based on this data, a 
nomograph of the relationship of reliability versus 
processing time and cost can be constructed. The 
nomograph is constructed by deriving the failure rate 
from the reliability, measures of repair time, and the 
cost of labor. An example of the' this type of 
nomograph is displayed in Figure 8. 

The nomograph can be used to determine what 
needs to be done to a process step. First, convert 


the allocated task time to corrective maintenance 
cost using average hourly labor costs. Then choose 
the appropriate MTTR curve and determine what 
reliability is required to meet the allocations. If that 
level of reliability does not seem reasonable then 
basic changes must be made to the process or the 
hardware. 

The final example of gap analysis is for on-pad 
launch delays. This is handled much like turnaround 
processing reliability. The current delay data was 
presented in Figures 5 and 6. Based on the design 
of the vehicle and ground systems some of those 
delays would not be applicable to the RLV, and 
would be excluded from the data. The remaining 
delay data can be statistically analyzed to determine 
the likelihood of launch or the confidence of having a 
launch over a given period. 

Table 6 illustrates some of the data that can be 
derived from delay data. This table compares the 


Shuttle operational history of delays to projections 
for an RLV. The RLV delays include all Shuttle 
delays for weather and all delays for system 
problems where the RLV has equivalent systems. 
For example, Shuttle Solid Rocket Booster problems 
would not be included, but most avionics problems 
would be included. 

The data in Table 7 cuts the data in several 
ways. The two major columns are for probability of 
launch anywhere in a launch window and for launch 
within the first five minutes of a launch window 
opening. The latter would be for missions to the 
Space Station that have only a five minute launch 
window. The rows cut the data into the probability of 
launch on the day scheduled at the Flight Readiness 
Review (FRR); the probability of launch on the first 
attempt, regardless of schedule; and the probability 
of launch on any attempt. Again this is for a generic 
RLV and actual designs will refine the estimates. 

' 'f 

Summary 

This paper has advocated and illustrated the use 
of continuous improvement techniques in the 
development of a new launch vehicle. 
Taking the operations data from an 
existing vehicle baseline and the 
requirements for a new vehicle as a 
goal, a systematic approach to vehicle 
and operation design can be found 
through continuous improvement 
techniques. 

The United States Air Force “Quality 
Focus" method was used as a 
methodology for continuous 
improvement. The methodology is 
based on the Shewhart Cycle which 
uses a four step process for 
improvement; plan, do, study and act. 
Or formulate, deployment, implement, 
and review for Quality Focus. 

In this paper we concentrated on the formulation 
stage. During this stage the organization must 
clearly identify the purpose of the process by 
identifying the organization's mission, customers, 
and the customer’s needs and requirements. Four 
steps of the formulation process are the key to the 
design: (1) Analyze the mission of the proposed 

system; (2) Determine the “vision" of the proposed 
system by determining the system goals and 
requirements; (3) Analyze current capabilities; (4) 
Determine the gap between the current capabilities 
and the vision. After determining the gaps to be 
filled, a strategy is developed for the design and 
development process of the launch system. 

Using the Total Quality Management techniques 
in the development of launch system provides a 
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Probability Of Launch Within 
Window 

Probability Of 
Five Minut 

Launch Within 
e Window 


Shuttle 

RLV 

Shuttle 

RLV 

First Scheduled Date 

.37 

.59 

.22 

.40 

First Attempt 

.56 

.74 

.27 

.51 

Any Attempt 

.57 

.72 

.28 

.5 

a n /m ir 
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operations it means working to streamline operations 
to those tasks that provide value to the customer. In 
addition, concentrating on customer value should 
also drive a more operations oriented design. 

The use of these techniques in the development 
of a new system does change the way we tend to 
operate. First and foremost of these is developing 
design discipline. In most projects there is a urge to 
dive into the design of a system before really 
defining the goal of the project or final product. 
Using a more systematic method has great benefits 
but requires more discipline. The second change is 
to place more emphasis on the -collection of 
operating data for a system. We need to determine 
the essential launch system data, including ground 
processing data, and to ensure it is collected. 
Unless this data is collected all future designs will be 
based on assumptions of what happened in the past 
rather than fact. 
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